home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-hanks-gre-00.txt < prev    next >
Text File  |  1993-09-09  |  16KB  |  449 lines
  1.  
  2.  
  3.  
  4. Network Working Group                                         Stan Hanks
  5. INTERNET DRAFT                            Technology Transfer Associates
  6.                                                                  Tony Li
  7.                                                           Dino Farinacci
  8.                                                              Paul Traina
  9.                                                            cisco Systems
  10.                                                        September 8, 1993
  11.  
  12.  
  13.                   Generic Routing Encapsulation (GRE)
  14.  
  15.                           Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard.  Distribution of this memo is
  19.    unlimited.
  20.  
  21.    This document is an Internet Draft. Internet Drafts are working
  22.    documents of the Internet Engineering Task Force (IETF), its Areas,
  23.    and its Working Groups. Note that other groups may also distribute
  24.    working documents as Internet Drafts.
  25.  
  26.    Internet Drafts are draft documents valid for a maximum of six
  27.    months. Internet Drafts may be updated, replaced, or obsoleted by
  28.    other documents at any time. It is not appropriate to use Internet
  29.    Drafts as reference material or to cite them other than as a "working
  30.    draft" or "work in progress".
  31.  
  32.  
  33. Introduction
  34.  
  35.    A number of different proposals [RFC 1234, RFC 1226] currently exist
  36.    for the encapsulation of one protocol over another protocol. Other
  37.    types of encapsulations [RFC 1241, SDRP, IDPR] have been proposed for
  38.    transporting IP over IP for policy purposes. This memo describes a
  39.    protocol which is very similar to, but is more general than, the
  40.    above proposals.  In attempting to be more general, many protocol
  41.    specific nuances have been ignored.  The result is that this proposal
  42.    is may be less suitable for a situation where a specific "X over Y"
  43.    encapsulation has been described.  It is the attempt of this protocol
  44.    to provide a simple, general purpose mechanism which is reduces the
  45.    problem of encapsulation from its current O(n^2) problem to a more
  46.    manageable state.  This proposal also attempts to provide a
  47.    lightweight encapsulation for use in policy based routing.  This memo
  48.    explicitly does not address the issue of when a packet should be
  49.    encapsulated.  This memo acknowledges, but does not address problems
  50.    with mutual encapsulation.  [RFC 1326]
  51.  
  52.  
  53.  
  54.  
  55. Expiration Date February 1994                                   [Page 1]
  56.  
  57. Internet Draft                                               August 1993
  58.  
  59.  
  60.    In the most general case, a system has a packet that needs to be
  61.    encapsulated and routed.  We will call this the payload packet.  The
  62.    payload is first encapsulated in a GRE packet, which possibly also
  63.    includes a route.  The resulting GRE packet can then be encapsulated
  64.    in some other protocol and then forwarded.  We will call this outer
  65.    protocol the delivery protocol. The algorithms for processing this
  66.    packet are discussed later.
  67.  
  68.  
  69. Overall packet
  70.  
  71.    The entire encapsulated packet would then have the form:
  72.  
  73.  
  74.                   ---------------------------------
  75.                   |                               |
  76.                   |       Delivery Header         |
  77.                   |                               |
  78.                   ---------------------------------
  79.                   |                               |
  80.                   |       GRE Header              |
  81.                   |                               |
  82.                   ---------------------------------
  83.                   |                               |
  84.                   |       Payload packet          |
  85.                   |                               |
  86.                   ---------------------------------
  87.  
  88.  
  89. Packet header
  90.  
  91.    The GRE packet header has the form:
  92.  
  93.  
  94.        0                   1                   2                   3
  95.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  96.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  97.       |C|R|K|S|s|        Flags    | Ver |       Protocol Type         |
  98.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  99.       |      Checksum (optional)      |       Offset (optional)       |
  100.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  101.       |                         Key (optional)                        |
  102.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  103.       |                    Sequence Number (optional)                 |
  104.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  105.       |                         Routing (optional)
  106.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  107.  
  108.  
  109.  
  110.  
  111. Expiration Date February 1994                                   [Page 2]
  112.  
  113. Internet Draft                                               August 1993
  114.  
  115.  
  116.       Flags and version (2 octets)
  117.  
  118.       The GRE flags are encoded in the first two octets.  Bit 0 is the
  119.       most significant bit, bit 15 is the least significant bit.  Bits
  120.       13 through 15 are reserved for the Version field.  Bits 5 through
  121.       12 are reserved for future use and MUST be transmitted as zero.
  122.  
  123.       Checksum Present (bit 0)
  124.  
  125.       If the Checksum Present bit is set to 1, then the Checksum field
  126.       is present and contains valid information.
  127.  
  128.       If either the Checksum Present bit or the Routing Present bit are
  129.       set, BOTH the Checksum and Offset fields are present in the GRE
  130.       packet.
  131.  
  132.       Routing Present (bit 1)
  133.  
  134.       If the Routing Present bit is set to 1, then it indicates that the
  135.       Offset and Routing fields are present and contain valid
  136.       information.
  137.  
  138.       If either the Checksum Present bit or the Routing Present bit are
  139.       set, BOTH the Checksum and Offset fields are present in the GRE
  140.       packet.
  141.  
  142.       Key Present (bit 2)
  143.  
  144.       If the Key Present bit is set to 1, then it indicates that the Key
  145.       field is present in the GRE header.  Otherwise, the Key field is
  146.       not present in the GRE header.
  147.  
  148.       Sequence Number Present (bit 3)
  149.  
  150.       If the Sequence Number Present bit is set to 1, then it indicates
  151.       that the Sequence Number field is present.  Otherwise, the
  152.       Sequence Number field is not present in the GRE header.
  153.  
  154.       Strict Source Route (bit 4)
  155.  
  156.       The meaning of the Strict Source route bit is defined in other
  157.       documents.  It is recommended that this bit only be set to 1 if
  158.       all of the the Routing Information consists of Strict Source
  159.       Routes.
  160.  
  161.       Version Number (bits 13-15)
  162.  
  163.       The Version Number field MUST contain the value 0.  Other values
  164.  
  165.  
  166.  
  167. Expiration Date February 1994                                   [Page 3]
  168.  
  169. Internet Draft                                               August 1993
  170.  
  171.  
  172.       are outside of the scope of this document.
  173.  
  174.       Protocol Type (2 octets)
  175.  
  176.       The Protocol Type field contains the protocol type of the payload
  177.       packet.  In general, the value will be the Ethernet protocol type
  178.       field for the packet.  Currently defined protocol types are listed
  179.       below.  Additional values may be defined in other documents.
  180.  
  181.       Offset (2 octets)
  182.  
  183.       The offset field indicates the octet offset from the start of the
  184.       Routing field to the first octet of the active Source Route Entry
  185.       to be examined.  This field is present if the Routing Present or
  186.       the Checksum Present bit is set to 1, and contains valid
  187.       information only if the Routing Present bit is set to 1.
  188.  
  189.       Checksum (2 octets)
  190.  
  191.       The Checksum field contains the IP (one's complement) checksum of
  192.       the GRE header and the payload packet.  This field is present if
  193.       the Routing Present or the Checksum Present bit is set to 1, and
  194.       contains valid information only if the Checksum Present bit is set
  195.       to 1.
  196.  
  197.       Key (4 octets)
  198.  
  199.       The Key field contains a four octet number which was inserted by
  200.       the encapsulator.  It may be used by the receiver to authenticate
  201.       the source of the packet.  The techniques for determining
  202.       authenticity are outside of the scope of this document.  The Key
  203.       field is only present if the Key Present field is set to 1.
  204.  
  205.       Sequence Number (4 octets)
  206.  
  207.       The Sequence Number field contains an unsigned 32 bit integer
  208.       which is inserted by the encapsulator.  It may be used by the
  209.       receiver to establish the order in which packets have been
  210.       transmitted from the encapsulator to the receiver.  The exact
  211.       algorithms for the generation of the Sequence Number and the
  212.       semantics of their reception is outside of the scope of this
  213.       document.
  214.  
  215.       Routing (variable)
  216.  
  217.       The Routing field is optional and is present only if the Routing
  218.       Present bit is set to 1.
  219.  
  220.  
  221.  
  222.  
  223. Expiration Date February 1994                                   [Page 4]
  224.  
  225. Internet Draft                                               August 1993
  226.  
  227.  
  228.       The Routing field is a list of Source Route Entries (SREs).  Each
  229.       SRE has the form:
  230.           0                   1                   2                   3
  231.           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  232.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  233.          |       Address Family          |  SRE Offset   |  SRE Length   |
  234.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  235.          |                        Routing Information ...
  236.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  237.  
  238.       The routing field is terminated with a "NULL" SRE containing an
  239.       address family of type 0x0000 and a length of 0.
  240.  
  241.       Address Family (2 octets)
  242.  
  243.       The Address Family field contains a 15 bit value which indicates
  244.       the syntax and semantics of the Routing Information field.  The
  245.       values for this field and the corresponding syntax and semantics
  246.       for Routing Information are defined in other documents.
  247.  
  248.       SRE Offset (1 octet) The SRE Offset field indicates the octet
  249.       offset from the start of the Routing Information field to the
  250.       first octet of the active entry in Source Route Entry to be
  251.       examined.
  252.  
  253.       SRE Length (1 octet)
  254.  
  255.       The SRE Length field contains the number of octets in the SRE.  If
  256.       the SRE Length is 0, this indicates this is the last SRE in the
  257.       Routing field.
  258.  
  259.       Routing Information (variable)
  260.  
  261.       The Routing Information field contains data which may be used in
  262.       routing this packet.  The exact semantics of this field is defined
  263.       in other documents.
  264.  
  265.  
  266.  
  267. Forwarding of GRE packets
  268.  
  269.  
  270.    Normally, a system which is forwarding delivery layer packets will
  271.    not differentiate GRE packets from other packets in any way.
  272.    However, a GRE packet may be received by a system.  In this case, the
  273.    system should use some delivery-specific means to determine that this
  274.    is a GRE packet.  Once this is determined, the Key, Sequence Number
  275.    and Checksum fields if they contain valid information as indicated by
  276.  
  277.  
  278.  
  279. Expiration Date February 1994                                   [Page 5]
  280.  
  281. Internet Draft                                               August 1993
  282.  
  283.  
  284.    the corresponding flags may be checked.  If the Routing Present bit
  285.    is set to 1, then the Address Family field should be checked to
  286.    determine the semantics and use of the SRE Length, SRE Offset and
  287.    Routing Information fields.  The exact semantics for processing a SRE
  288.    for each Address Family is defined in other documents.
  289.  
  290.    Once all SREs have been processed, then the source route is complete,
  291.    the GRE header should be removed, the payload's TTL MUST be
  292.    decremented (if one exists) and the payload packet should be
  293.    forwarded as a normal packet.  The exact forwarding method depends on
  294.    the Protocol Type field.
  295.  
  296.  
  297.  
  298. Current List of Protocol Types
  299.  
  300.  
  301.    The following are currently assigned protocol types for GRE.  Since
  302.    this is considered a differnet media type, there is no need for
  303.    multiple encapsulations based upon media type.  If there are multiple
  304.    encapsulation methods for various media types, the ethertype should
  305.    be used.  Selection for encodings are made according to this scheme:
  306.  
  307.    1. Use the DIX ethernet encoding (e.g. 0x0800 = IP)
  308.  
  309.    2. If the protocol is encoded with the SNAP LSAP, use the
  310.       SNAP protocol ID field (ethernet encoding).  (e.g. 0x0800 = IP)
  311.  
  312.    3. Use 00 followed by the LSAP   (e.g. 0x00FE = OSI network layer)
  313.  
  314.    4. Full SNAP encoding with a non zero OUI field is reserved for
  315.       proprietary use.  In this case, 0x00AA should be used for the
  316.       GRE protocol type and the OUI and additional encodings immediately
  317.       follow the GRE header.
  318.  
  319.    These values have been computed using this scheme and MUST be used to
  320.    identify the following protocols:
  321.  
  322.        Protocol Family                     PTYPE
  323.        ---------------                     -----
  324.        SNA                                 0004
  325.        SNAP encoding (OUI follows GRE)     00AA
  326.        OSI network layer                   00FE
  327.        PUP                                 0200
  328.        XNS                                 0600
  329.        IP                                  0800
  330.        Chaos                               0804
  331.        RFC 826 ARP                         0806
  332.  
  333.  
  334.  
  335. Expiration Date February 1994                                   [Page 6]
  336.  
  337. Internet Draft                                               August 1993
  338.  
  339.  
  340.        Frame Relay ARP                     0808
  341.        VINES                               0BAD
  342.        VINES Echo                          0BAE
  343.        VINES Loopback                      0BAF
  344.        DECnet (Phase IV)                   6003
  345.        Ethertalk                           809B
  346.        Apollo Domain                       8019
  347.        Novell IPX                          8137
  348.  
  349.    In addition, the following values are specified:
  350.  
  351.        Reserved                            0000
  352.        Transparent Ethernet Bridging       6558
  353.        Raw Frame Relay                     6559
  354.        IP Autonomous Systems               fffe
  355.        Reserved                            FFFF
  356.  
  357.  
  358.  
  359. Security Considerations
  360.  
  361.    Security considerations are not discussed in this memo.
  362.  
  363.  
  364. Acknowledgements
  365.  
  366.    The authors would like to acknowledge Yakov Rekhter (IBM) and Deborah
  367.    Estrin (USC) for their advice, encouragement and insightful comments.
  368.  
  369.  
  370. Authors'  Addresses:
  371.  
  372.    Stanley P. Hanks
  373.    Technology Transfer Associates
  374.    P.O. Box 2087
  375.    Bellaire TX, 77402
  376.    stan@tta.com 
  377.  
  378.  
  379.    Tony Li
  380.    cisco Systems, Inc.
  381.    1525 O'Brien Drive
  382.    Menlo Park, CA 94025
  383.    tli@cisco.com
  384.  
  385.  
  386.    Dino Farinacci
  387.    cisco Systems, Inc.
  388.  
  389.  
  390.  
  391. Expiration Date February 1994                                   [Page 7]
  392.  
  393. Internet Draft                                               August 1993
  394.  
  395.  
  396.    1525 O'Brien Drive
  397.    Menlo Park, CA 94025
  398.    dino@cisco.com
  399.  
  400.  
  401.    Paul Traina
  402.    cisco Systems, Inc.
  403.    1525 O'Brien Drive
  404.    Menlo Park, CA 94025
  405.    pst@cisco.com
  406.  
  407.  
  408. References
  409.  
  410.  
  411. IDPR
  412.      Steenstrup, M. "Inter-Domain Policy Routing Protocol Specification:
  413.      Version 1". Work in progress.
  414.  
  415. RFC 1226
  416.      Kantor, B. "Internet protocol encapsulation of AX.25 frames", May
  417.      1991
  418.  
  419. RFC 1234
  420.      Provan, D. "Tunneling IPX Traffic through IP Networks". June 1991
  421.  
  422. RFC 1241
  423.      Woodburn, R.A.; Mills, D.L.  "Scheme for an internet encapsulation
  424.      protocol: Version 1".  July 1991
  425.  
  426. RFC 1326
  427.      Tsuchiya, P. "Mutual Encapsulation Considered Dangerous". May 1992
  428.  
  429. SDRP
  430.      Estrin, D., Li, T., Rekhter, Y. "Source Demand Routing Protocol
  431.      Specification (Version 1)". Work in progress.
  432.  
  433. GRE-IP
  434.      Hanks, S., Li, T., Farinacci, D., Traina, P. "Generic Routing
  435.      Encapsulation over IPv4 networks". Work in progress.
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447. Expiration Date February 1994                                   [Page 8]
  448.  
  449.